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ABSTRACT 

“System Requirements Language” here refers to those languages (defined by a formal set of syntax 
rules and semantics) whose purpose is the explicit and comprehensive expression of system defi- 
nition and design facts. Not only is a formal requirements language necessary in specifying pre- 
cisely the functional and performance characteristics of the system at all levels of definition and 
design, but at the same time this information can be used to predict the costs in time and money 
required to develop, implement, operate, and maintain a proposed system. Other benefits derived 
from this information include the direct generation of system and environment models used in the 
analysis of design solutions, direct generation of test criteria to be used during the test and inte- 
gration phases of system development and the providing of a vehicle for maintaining configuration 
control throughout the life cycle of the system. “System” refers to not only software systems 
developed with “Software Development Methodologies”, it also refers to the methodologies 
themselves. 

1. MOTIVATION 

According to a number of articles written recently [4,6] the costs of software development are 
becoming dominant (i.e., 50 to 90 percent of the cost of future data processing systems). In spite 
of the proliferation of programming languages [1] and software development techniques devised 
during the past 15 to 20 years, progress in reducing the costs of software has been disappointing. 
One source has indicated a decrease in productivity over this same period [3] . 

After a cursory analysis of major software developments, it appears that the industry has been 
attacking the wrong problem. A very large percentage of software development costs are associated 
with the definition, design, testing, and integration activities. The development of programming 
languages and techniques has been directed mainly toward the coding activity which represents 
only a small percentage of software development (as low as 17% for a large 7.5 year project [6] ). 

If the software industry is expecting to see large reductions in the cost of software, it must attack 
those problems connected with definition, design, testing and integration activities representing 
anywhere from 45 to 85 percent of most data processing development costs. 

The first step in attacking the cost of these activities appears to be the development of a precise, 
yet convenient, system requirements specification and analysis language. Teledyne Brown En- 
gineering has been actively involved in this type of development since 1971 and has devised a 
requirements language called lORL (Input/Output Requirements Language) which claims the 
objectives of the preceding discussion. 
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2. lORL 


/ 


lORL is a formally defined language (syntactically and semantically [2,5] which uses a combi- 
nation of both graphic symbols and mathematical notation to express system definition and de- 
sign ideas. Block diagrams (analogous to those used in control theory) organized in a hierarchi- , 
cal manner identify the parts of a system and the interfaces between these parts at all levels of 
system definition and design. 

Descriptions of each interface identified are contained in a set of tables called lOPT’s (Input/ 

Output Parameter Tables). Another diagram called in “lORTD” (Input/Output Relationships 
and Timing Diagram) is used to define the total transformation function from input to output 
as well as the response time requirements for each and every block in the hierarchy. These 
diagrams (analogous to.a “Transfer Function” in contrortheory)^rovide the symbols for spec- 
ifying the sequential, simultaneous, logical, mathematical and time requirements between inputs 
and outputs of each given block. The elements of lORL and hierarchical structure of require- 
ments information are characterized in Figures 1 and 2. 

3. lORL STORAGE AND RETRIEVAL FACILITY 

Storage, retrieval and modification of lORL diagrams and tables has been implemented on a stand- 
alone PDP/1 1 based graphics terminal (GT44 and GT46) with 16K memory. The interactive 
graphics system includes a 1 74nch refresh type graphic screen with lightpen capability as well 
as an electrostatic printer plotter which produces 8.5 x 1 1 inch copies of the screen. In edit mode, ■ 

lORL information is entered by pointing the lightpen at a location on the screen and then pres- 
sing the keyboard button associated with the desired symbol. In display mode, system details 
are accessed by directing the lightpen to points of interest on the higher level diagrams of the 
hierarchy. This results in the subsequent display of these details on the screen. Requirements 
diagrams are stored on and retrieved from disk packs which are also a part of the facility. 

■4. BALLISTIC MISSILE DEFENSE (BMP) PARTITIONING STUDY EXAMPLE 

Not only is a formal requirements language necessary in specifying precisely the functional and 
performance characteristics of the system at all levels of definition and design, but at the same time 
this information can be used to predict the costs in time and money required to develop, imple- 
ment, operate and maintain a proposed system. Other benefits derived from this information 
include the direct generation of system and environment models used in the analysis of design 
solutions, direct generation of test criteria to be used during the test and integration phases of 
system development and the providing of a vehicle for maintdning configuration control through- 
out the life cycle of the system. 

In an attempt to determine the feasibility of the preceding thesis, a study entitled “BMD Par- 
titioning Study”, was performed. The objective of this study was to demonstrate that certain 
quantitatiave characteristics, related to system development and operation costs, could be de- 
rived directly and mechanically from formally defined system requirements specifications. lORL 
was used as the language for specifying the definition and design requirements. 

The demonstration consisted of four basic steps. First, the BMD system requirements and its 
environment were defined using the complete set of lORL symbols, tables and diagrams. This 
information, which represented the first level in the system hierarchy, was the only infor- 
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mation used in the subsequent requirements analysis and design activities. After checking the 
first level specification for completeness and consistency, the second step involved designing two 
different solutions to the BMD requirements, again expressing these solutions in lORL and pla- 
cing this information in the second level of the system hierarchy. The purpose in specifying two 
design solutions was to compare the total system costs which resulted from each of the solutions. 

In the third step, each completely specified solution was validated against the BMD requirements 
by exercising the environment, BMD, and solution models (all written in lORL) and then com- 
paring responses at the BMD/environment interfaces. 

In this manner it was established that each solution responded to the environment exactly as re- 
quired by the BMD requirements (model). If not, the design solution was corrected. In the final 
step, each solution was evaluated to determine its effect on total system costs. This evaluation, 
which was a combination of static and dynamic analysis of only that information contained in 
the lORL specifications, produced the summary partition evaluation results shown in Figure 6. 
These summary results were derived from a series of intermediate results which plotted for exam- 
ple bandwidth for each interface as a function of time, storage required as a function of time, 
functional speed require4, etc. 

Our experience with this study has resulted in the following conclusions: 

• Quantitative measures related to the costs of a system can be determined from an 
analysis of system definition and design requirements. 

• The requirements language used to specify system definition and design facts is the 
key factor in the success of the preceding demonstration (i.e., the language must have 
certain characteristics and enforce certain disciplines). 

• The proper specification of definition and design requirements can provide information 
necessary to all phases of a system development (definition, design, implementation, test 
and integration). 

5. FUTURE R&D ACTIVITIES 

Teledyne Brown Engineering has plans to continue the development of lORL related techniques and 
tools. The immediate future calls for the development of the following computer utility packages: 

• An extensive lORL diagnostic package (syntax analyzer) 

• A set of configuration management tools 

• An expended set of graphic editing features for the storage and retrieval system 

• A utility program library 

• A set of functional and analytic simulation compilers which will transform lORL infor- 
mation into FORTRAN or PASCAL simulation statements. 
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We have also experimented with the direct generation of assembler source code (Marco-II 
Assembler) from lORL information and have deterrhined that the information content of lORL 
will support the development of a set of lORL compilers. The major problems associated with this 
last activity are the implementation of mathematical functions so easily represented in lORL. 
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CURRENT CAPABILITIES - STORAGE AND RETRIEVAL 
OF REQUIREMENTS USING INTERACTIVE GRAPHICS 


• BASIC STORAGE AND RETRIEVAL OF INFORMATION 

A DISK PACKS ( 1 200 PAGES/PACK) 


ON LINE EDITING 


A 

A 

A 


HARDCOPY 


CLASSIFIED FACILITY 


CRT 

LIGHT PEN 
FUNCTION KEYS 


REPORT QUALITY 


• DOCUMENTATION AUDIT 

• MERGE SYSTEM PAGES 

• AUTOMATIC ACCOUNTING 

Figure 3. Current Capabilities — Storage and Retrieval 
of Requirements Using Interactive Graphics 
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SYSTEM CONFIGURATION 


• PDF- 1 1 /40 WITH 1 6K MEMORY 

• 17" GRAPHIC DISPLAY WITH LIGHTPEN 

• TELETYPE 

• 2 DISK DRIVES 

• ELECTROSTATIC PRINTER/PLOTTER ( 8 Y 2 X 1 1 FAN FOLD) 

Figure 4. System Configuration 
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COMPUTERIZED ANALYSIS (PARTITIONING STUDY) 


COMPUTERIZED 

SYSTEM 

REQUIREMENT 

SPECIFICATION 

LIBRARY 


REVISIONS 


COMPUTERIZED 

REQUIREMENTS 

VALIDATION 

PROCESS 



COMPUTERIZED 

REQUIREMENTS 

SIMULATION 

PROCESS 


DIAGNOSTICS 


COSTS 

(RELIABILITY) 
(STORAGE) 
(SPEED) 
(BANDWIDTH) 
(DEV. EFFORT) 


SYSTEM 

ANALYSTS 



FIGURE 5. COMPUTERIZED ANALYSIS (PARTITIONING SYSTEM) 
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PARITITION EVALUATION RESULTS 



PARTITION 1 

PARTITION 2 





TOTAL 




TOTAL 





OR 




OR 


GNO 

TRKER 

SENSOR 

WORST 

GNDSVS 

sncoR 

SENS 

WORST 

RELIABILITY 

0.975 

0.900 

0.975 

0.941 

0.980 

“ ■ 1 

0.980 

0.980 

0.941 

STORAGE 

23.5 

389.3 

2.67 

804.8 

138.6 

284.4 

27.9 

432.7 

(KBITS) 


(2) 







PROCESS 

SPEED 

(nSEC) 

5.44 

5.85 

5.56 

5. 44 

0.814 

0.814 

0.814 

0.814 

PROGRAMMING 

COMPLEXITY 

(MAN-MONTHS) 




35.65 




26.3 

PEAK BANDWIDTH 
(MBITS/SEC) 




2.52 




20.94 


FIGURE 6. PARTITION EVALUATION RESULTS 
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TOTAL SYSTEM DEVELOPMENT PROCESS 


00 



FIGURE 7. TOTAL SYSTEM DEVELOPMENT PROCESS 







FUTURE lORL RESEARCH AND DEVELOPMENT 


• DIAGNOSTICS PACKAGE (SYNTAX ANALYZER) 

• CONFIGURATION MANAGEMENT TOOLS 

• EXPANDED EDITING FEATURES (GRAPHICS) 

• UTILITY PROGRAM LIBRARY (STATIC ANALYSIS) 

• SIMULATION COMPILER 

A FUNCTIONAL: “lORL” TO “MODELER” TRANSLATOR 
A ANALYTIC; “lORL” TO “FORTRAN” TRANSLATOR 

• COMPILER 

A “lORL” TO “FORTRAN” TRANSLATOR 
A “lORL” TO “PDP- 11” MACRO- ASSEMBLER” TRANSLATOR 

Figure 8. Future lORL Research and Development 
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